LGTM!

Minor findings for some future thing to look at. Would merge without any of these:

1. uuid@<4: ^11.1.1 leaves request non-loadable. request@2.88.2's lib/{auth,oauth,multipart}.js all do require('uuid/v4'); that subpath was removed in uuid 7 and uuid 11.1.1's exports map only declares . and ./package.json. Verified: ERR_PACKAGE_PATH_NOT_EXPORTED: Package subpath './v4' is not defined. request@2.88.2 is the override's only consumer, and phantomjs-prebuilt is request's only consumer, so nothing loads it today (there's no pnpm.onlyBuiltDependencies, so pnpm 10 runs no install scripts). Net: a CVE row traded for a latent module-resolution failure.
2. The real fix for that cluster is deleting phantomjs-prebuilt. It's a dead devDependency: no karma, tests are jest + jsdom, and nothing in src/, pom.xml, or webpack.config.js references it. Dropping it removes request and with it uuid@3, form-data@2, tough-cookie, sshpk, http-signature, hoek, stringstream, qs, extend, har-validator, lets you delete ~6 overrides, and retires the "request 6.1 / not fixed" row outright.
3. tar: ^7.5.21 is also inert. cacache@15.3.0 declares tar: ^6.0.2 but has zero require('tar') anywhere in its JS. Keep it (it undoes an override that was actively forcing tar down to 4.4.19, which is the real find here), but the body's "Transient (cacache via copy-webpack-plugin / terser-webpack-plugin)" implies a live code path that doesn't exist.
4. loader-utils scope claim is understated. Four packages resolved 0.2.17, not one: string-replace-webpack-plugin@0.1.3 plus the css-loader@0.9.1 / file-loader@0.8.5 / style-loader@0.8.3 it declares as deps. All four moved to 1.4.2. Outcome is still fine (see Cleared), but "the only vulnerable copy" isn't accurate.
5. ip-address 10.2.0 → 10.5.0 changes released validation behavior. Probed 24 inputs across both versions; exactly one delta: leading-zero IPv4 octets now throw. 010.1.1.1, 1.2.3.04, 01.02.03.04 flip from valid to invalid. That feeds isValidIPAddress in admin/newInterface.jsp, admin/discovery/add-{specific,er,ir}.jsp, buildPathOutage.jsp, setPathOutage.jsp, and requisition constraints. 10.2.0 shipped in opennms-36.0.2-1, so this is a change to released behavior and belongs in the description. It's hardening (ambiguous octal), but note Java's InetAddress reads 010.1.1.1 as decimal 10.1.1.1, so the UI now rejects what the backend accepts.
6. checkIpRange is broken for IPv6, and the test suite can't see it. Address6#bigInt() returns a native BigInt, so b.bigInt().compareTo(a.bigInt()) throws TypeError on both 10.2.0 and 10.5.0. Not a regression (predates this PR, back to the ip-address 9 move off jsbn), but add-er.jsp / add-ir.jsp range validation is dead for IPv6 and ipaddress.test.js only covers an IPv4 range, so "169 tests passing" doesn't touch it.
7. TypeScript 6.0 buys nothing on a release branch. No script runs tsc; webpack transpiles via babel and there's no ts-loader, so "build passes" doesn't exercise the compiler. Actual consumers are ts-jest (peer >=4.3 <7, fine) and @typescript-eslint 7.18.0, whose SUPPORTED_TYPESCRIPT_VERSIONS is >=4.7.4 <5.6.0 and which was already out of range at 5.9.3. So nothing newly breaks, but a compiler major on release-36.x with a linter three majors behind is risk without payoff; the change that would actually help is @typescript-eslint 8.x on develop.
8. .node-version still says 16.15.1 while engines says >=22 and tar@7 requires >=18. Maven pins nodeVersion v22.22.2 so CI is unaffected; local nvm/fnm users land on a Node the tree no longer supports. Cheap drive-by fix.
9. ^ ranges on CVE pins drift. The body itself records two overshoots (@babel/core 7.29.6→7.29.7, ip-address 10.3.1→10.5.0), and install-deps is pnpm install --prefer-offline with no--frozen-lockfile, so a non-CI build can silently re-resolve past what was tested.

Changes look good.

I think the changes looks good;

Given that we are now being strict when it comes with IP Addresses (for example we reject ones starting with 0), should we add a warning in the breaking changes on our Docs?